第四週的六篇，起點是一夜 $40 的帳單，終點是一份設定檔和幾支檢查腳本。

這種事情業界有個詞叫 LLMOps，通常出現在企業簡報裡，配著平台架構圖和治理委員會的組織圖。我要先把話說清楚，免得這篇讀起來像在自抬身價：

**我做的不是那種東西。**我做的是一個 JSON 設定檔（寫著能用哪些模型、月費上限多少）、幾支每天跑的檢查腳本、一份 PR 檢查清單。全部加起來不到一千行程式碼。

之所以還是借用「治理」這個詞，不是為了聽起來厲害，是因為我想不到更短的說法來描述「先把規則寫下來，再讓機器去執行它」這件事。如果你覺得這個詞太大，把它換成「幾條家規」也完全成立——重點從來不在詞，在於規則有沒有被真的執行。

再把話說得更直白一點：真正的企業級治理是很大、很難的題目——組織、法遵、稽核、職責分離，每一塊都是專門的職業，不是幾支腳本能替代的。而我這個一人專案裡的很多做法，放到企業環境根本不合規：開發、審核、部署從頭到尾是同一個人（任何內控框架都過不了這關）、紀錄只留三十天、變更管理是我自己跟自己開 PR。這個差距明天會整篇攤開來講。所以請把這篇的定位放在「概念分享」：一個人、用業餘時間和幾乎零預算，怎麼把「規則寫成機器能執行的樣子」這個治理最核心的概念跑起來——概念可以直接帶走，做法請按你的環境重新料理，別照抄。

而如果把「概念」再壓縮到最小，它其實就是一個迴圈：

遇到問題 → 動手處理 → 把教訓寫進記憶（檔案、規則、檢查）→ 下一輪迭代。

本週的每一條規則都是這個迴圈轉出來的：$40 轉出模型白名單、誤報 31 次轉出「誤報是 P1」、掃了兩個月空氣轉出反向驗證。五根柱子不是我某天設計出來的架構——是這個迴圈跑了半年沉澱下來的形狀。所以你真正要帶走的不是柱子，是迴圈：柱子長什麼樣取決於你踩到哪些坑，但迴圈對每個人都一樣。

今天把這週收攏成五件事，然後交付一份可以直接抄走的檢查清單。

Week 4 六天回顧

治理五支柱

回頭看，六篇其實是五類規則。我用「支柱」稱呼它們純粹是為了好記，它們的實體是五個資料夾裡的十幾個檔案，沒有平台、沒有儀表板產品、沒有委員會：

① 成本閘道（Day 22、23、24）——LLM 系統獨有的故障型態是「一切正常但在燒錢」。對策是把成本規則寫成可機器判定的硬約束：模型白名單、fallback 必空、timeout 上限，再加一條費用告警當最後防線。

② 品質監控（Day 24、25）——規則要有警察。每日掃描抓違規、每小時守衛抓故障、每月評分抓趨勢。以及那條反直覺的鐵律：誤報比漏報更急著修，因為誤報殺死的是整個告警系統的信用。

③ 安全紅線（Day 26、27）——秘密只活在憑證管理器和環境變數層；LLM 可讀層只放指標不放值；給 LLM 的工具參數空間收到最窄。紅線的共同邏輯：LLM 的行為是機率分布，安全設計只能靠縮小它能觸碰的範圍，不能靠祈禱它不出錯。

④ 可觀測性（Day 25）——「系統還好嗎」必須有數字答案。三種時間尺度各配一個機制，指標只留「看到會行動」的那幾個。

⑤ 變更治理（貫穿全系列）——前面四根柱子全都是程式碼實現的，那程式碼本身怎麼改？半年前我的答案很誠實：直接在同步資料夾裡改，存檔，等它同步上去。這個做法有兩個問題，而且都咬過我。

第一個是同步資料夾等於生產環境。工作區靠檔案同步推到 NAS，同步工具搬的是「檔案現在長什麼樣」，它不看 git 分支。所以在同步夾裡切一個實驗分支，等於把未驗證的程式碼直接推上生產。我後來的做法是：同步夾永遠停在主線，任何改動都在同步範圍外的獨立工作樹進行，驗證過了才合併回來。

第二個是沒有閘門的變更會累積成技術債。現在每個改動走同一條路：獨立工作樹 → 本機驗證 → 開 PR → 三道自動檢查（機密掃描、語法檢查、單元測試）→ 合併 → 自動部署 → 生產複驗。聽起來像大公司流程，但實作成本其實很低——幾支腳本，一個免費的 CI，加起來不到一個週末。

換來的東西很具體：我可以放心地讓 AI 改自己的程式碼。因為每一步都有機器把關，錯誤在合併前就會被擋下來，而不是等系統在半夜壞掉才發現。

也踩過對應的坑。測試指令原本是硬編碼的一長串 node a.test.js && node b.test.js && …，新增的測試檔如果沒被加進清單就不會執行。某次盤點才發現，十七個測試檔裡有六個從來沒跑過，其中兩個是安全回歸測試——寫了、CI 也顯示綠燈，但那道防線從未被驗證過。改成自動掃描目錄之後才恢復正常。這件事的教訓不是「要寫測試」，是「要確認你的測試真的在跑」。

五根柱子有先後順序嗎？有。成本閘道最先——因為它是唯一連著信用卡的；可觀測性其次——看不見就治理不了；安全和品質可以事故驅動地補。變更治理則是地基——它不解決任何單一問題，但沒有它，其他四根柱子的修補會一次次被自己的隨性推倒。這是我用半年試錯排出來的優先級，如果你只想做一件事，做第一根；如果你打算長期維護，先鋪第五根。

交付物：個人 AI 系統治理 Checklist

把四根柱子壓縮成一頁。如果你也在跑（或打算跑）一個會自主呼叫 LLM 的系統，對著勾：

成本

• [ ] 每個自動化任務都「顯式」指定模型，沒有任何任務依賴預設值
• [ ] 排程／自動化語境禁用旗艦模型——我家是 Claude 旗艦只留互動（白名單強制，不靠自覺）
• [ ] fallback 鏈裡沒有「比主模型更貴」的模型（最好整條清空）
• [ ] 每個任務有 timeout 上限與重試次數上限
• [ ] API 服務商後台設了費用告警，閾值是「日常量的 2–3 倍」而不是月預算

可觀測性

• [ ] 任務的執行紀錄可以回查（誰、何時、用什麼模型、花多少）
• [ ] 有一個機制回答「該跑的任務沒跑」（殭屍偵測）
• [ ] 靜默失敗的通道（發到不存在的頻道之類）有白名單防護
• [ ] 費用曲線是一級監控指標，和 uptime 同級

安全

• [ ] 版本庫掃過一輪：沒有憑證檔、remote URL 裡沒有 token
• [ ] LLM 會讀到的所有檔案（記憶、筆記、設定）裡沒有明文秘密
• [ ] 給 LLM 的工具沒有「任意 shell」等自由字串大權限
• [ ] LLM 不能刪除檔案、不能改自動化設定（或至少要過人工關卡）

品質

• [ ] 治理規則寫成文件，而且是 Agent 每次啟動會讀的那份
• [ ] 有排程在掃描規則違規（法律要有警察）
• [ ] 誤報被當成 bug 修，而不是「習慣就好」
• [ ] 每次事故有一段「現象→根因→解法」的筆記

十七條，一個週末可以檢完。我自己在三個月前大概只能勾一半——每個沒勾的格子，後來都變成了這個系列某一篇的素材。

治理的成本，值得嗎

老實面對一個質疑：個人系統搞這套，會不會過度工程？

我的帳是這樣算的。四根柱子的建置成本：閘道文件一個晚上、掃描腳本兩三個晚上、評分腳本一個週末、安全審查一個週末——合計大約兩週的業餘時間。維護成本：每月看一次報告十分鐘、違規批次修半小時。

而它們對沖掉的風險：$40 級的成本事故（已發生一次，之後零復發）、殭屍 job 空轉的浪費（發生過，兩週的無效 API 呼叫）、憑證洩漏（三個真實漏洞，修復含撤銷重發）。治理投資在第一次「本來會發生但沒發生」的事故時就回本了。

更誠實地說：治理省下的不只是錢，是信任。我敢讓這套系統在我出差一週時無人看管地跑，是因為知道它花不了大錢、壞了會叫、秘密不在明處。

但我要在這裡自己打斷一下，因為上面那句話差點就成了這個系列最大的謊。

我的合規掃描，掃了兩個月的空氣

寫這篇的時候，我對「每日掃描抓違規、零違規」這個數字很滿意。後來去讀那支掃描腳本，才發現它做了這樣一件事：

它從資料庫撈出所有排程，讀每一筆的 model 欄位，拿去比對白名單。問題是——排程的模型設定不在 model 欄位，在 payload.model 裡面。

所以它每天讀到的都是 undefined，比對「undefined 有沒有違規」，答案永遠是沒有。這支腳本從第一天起就不可能報出違規，而我看著它天天回報「全數合規」，還以為自己的治理很有效。

修好之後我做了一次反向驗證：故意塞一個違規設定進去，確認它會叫；再拿掉，確認它安靜。這一步以前從來沒做過——而它只要三分鐘。

跟 Day 25 那條全是 0 的費用曲線一樣，這段掃描程式碼也是 AI 助手寫的，而且壞法一模一樣：語法對、邏輯順、跑起來不噴錯，只是讀錯了一個欄位。

我不覺得這是「AI 不可靠」的證據——換成我自己手打，一樣會把欄位名記錯。真正的差別在速度：實作變快之後，我一天可以長出好幾支這樣的檢查，而我審查它們的速度並沒有跟著變快。

所以這一週真正的教訓不是「要做治理」，是：**當產出的速度超過驗證的速度，你的系統會開始累積「看起來在保護你、其實沒有」的東西。**PR 閘門、自動測試、反向驗證——這些都不是流程潔癖，它們是我唯一能追上自己產出速度的辦法。

把這件事跟 Day 28 前面講的「六個測試從來沒被執行」放在一起看，會浮出同一個模式：

一個從來不報錯的檢查，跟一個不存在的檢查，在儀表板上長得一模一樣。

所以如果要我修改前面那段對治理的推銷，我會加上一句：**沒有治理的自動化你只敢讓它做玩具；有治理的自動化你敢交付真實生活——前提是你驗證過那些治理真的會叫。**否則你買到的不是安全，是安全感，而後者比沒有更危險，因為它會讓你停止檢查。

小結＋明日預告

一句話：治理的本質是把「希望它不出事」換成「它出事的方式都在預算內」——最小可行版本，一個人、兩週業餘時間、零額外月費就能做到。不需要平台，不需要委員會，需要的是把規則寫成機器能判定的樣子，然後定期確認那台機器真的在判定。

寫到這裡，一個職業病發作的問題一直在我腦中盤旋：家裡這套治理，如果搬進我白天工作的那種環境——銀行——夠用嗎？明天做一場思想實驗：金融 IT 人的合規推演。

🔑 這篇的關鍵字
核心迴圈：遇到問題 → 處理 → 寫進記憶 → 迭代——五支柱是迴圈沉澱的形狀，不是設計出來的架構；帶走迴圈，別帶走柱子
一人專案的治理是概念分享不是合規範本：開發/審核/部署同一人在企業過不了內控（差距見 Day 29）
個人版 LLMOps 的五類規則：成本 / 品質 / 資料 / 安全 / 變更
變更治理：隔離工作樹（同步資料夾恆保持主線）· PR 當部署閘門 · 自動測試 + 自動部署 + 生產複驗
⚠️ 測試指令別硬編碼檔名清單——改成掃描目錄，否則新增的測試不會被執行
⚠️ 合規掃描要反向驗證：塞假違規確認會叫、拿掉確認會安靜。三分鐘的事
核心教訓：當產出速度超過驗證速度，你會開始累積「看起來在保護你、其實沒有」的東西

我是一名金融業資訊工程師，這是我半年來在家自架 AI Agent 系統的實錄。